There are issues in the javadoc that will cause the docs target to fail, e.g. mismatched blockquote. Can you fix these up so that we can generate the docs from the changes in the PR?

Is there an easy way to test the correctness of the javadoc parts (I couldn't find an option for javadoc). The </blockquote >above is matched to a <blockquote> on line 88, but there is a <pre></pre> pair in between, is that the issue you are referring to?

make docs. The second blockquote is matched with another blockquote, not </blockquote>. In the example, which can be converted to a snippet, then then braces not matched so the end brace for {@code ... } get mixed up.

I see that now - fixing ....

I also removed the nested {@code ..} from within the <pre></pre> as that also caused an issue

Good. You can move the example to a snippet too and that will allow the <pre> tags to go away.

In the latest CSR the code snippet was removed

This uses MF.getPlatformMXBean in the child VM. A more complete test would repeat with:

        MBeanServer server = ManagementFactory.getPlatformMBeanServer();
        HotSpotAOTCacheMXBean bean = ManagementFactory.newPlatformMXBeanProxy(server,
                "jdk.management:type=HotSpotAOTCacheMXBean",
                HotSpotAOTCacheMXBean.class);

In any case, it might be simpler to test that the MXBean is registered in the test itself, it doesn't need to be in the child VM.

Thanks Alan, I changed the code per your recommendation to not use ManagementFactory.getPlatformMXBean

Someone is bound to ask what happens if the "endRecording" operation is performed concurrently and there is recording in progress. Does one or all return true? I don't think it matters, the bigger issue here is that returning false means the recording has already ended or it failed. If it failed, why did it fail? I realize the intention is to add some properties and further operations to this MXBean but I think it would be good to think through if starting with a boolean returning operation is going to be problematic in the future.

I see a couple of cases for when endRecording is called:

1. Within the same process to generate a cache - given the api will only return true to one caller, that caller is the only one who can be responsible for taking further action (copying the cache somewhere, etc). Already ended or failed makes no difference operationally.

2. From a monitoring process - again only the successful case matters. All failures (already ended or failed) are indistinguishable. No further action can be taken by the observer. It's only the success case that matters

Please don't use bare URLs. Change these to

... please refer to JEPs <a href="https://openjdk.org/jeps/483">483</a> and
<a href="https://openjdk.org/jeps/514">514</a>.

fixed

Minor nit is that we usually use 4-space rather than 2-space indent in the java sources. You might want to check the /** .. */ comments in a few of the files as they are misaligned in a few places.

Is test-classes used?

In addition to testing the endRecording operation, we also need to test both the direct and indirect access to the MXBean. The test currently obtains a proxy with newPlatformMXBeanProxy (good) but the direct access with ManagementFactory.getPlatformMXBean is not tested right now.

Another thing to test is that getObjectName returns the expected object name.

Have you considering have the child terminate with an exception so the exit status is non-0. If you get a success status then the output should have the expected strings. A non-0 would failure, and the test fails.

trivial missing space nit (){

This assignment is unusual. Are we trying to avoid a synchronized block? Other nameToMBeanMap() methods are like:
return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME, ManagementFactoryHelper.getMemoryMXBean());

..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized and creates the impl if needed.

I don't see a correctly issue with this. Maybe in the future we will be able to use LazyConstant here.